Current Video On Demand (VOD) solutions suffer from inefficient coupling of storage and streaming capacity which results in high operational costs. Albeit some emerging remote storage architectures, the bulk of any VOD network relies on devices streaming through Direct Attached Storage (DAS) in order to achieve good I/O performance of HDD media. Using standard techniques, it is therefore desirable to foresee what content will be requested at any given location, which drives different distribution and caching algorithms.
Most VOD systems opt to place faster devices with high-throughput closer in the network to where the demand is; since it is impractical to place all the content at that devices, only the expected popular content is distributed to these devices; in case of a “miss”, content needs to be streamed from an upstream location, which means higher latency and more network traffic.
As storage costs are constantly on decline it is becoming a common practice to employ masses of storage capacity on distributed devices and to introduce a large amount of content duplication. Since each streaming device becomes a centralized server for its serving population it needs to become very scalable and to reach high I/O throughput. This creates a race between the VOD servers for who can stream more out of an “off the shelf” server which in essence commoditized their business. In addition, user demand for more content hours is growing in an overwhelming rate. The approach of “duplicate all everywhere” can not scale to the future world of Long-Tail Content, dealing with tens to hundreds of content hours.
A commonly used file sharing mechanism is known as BitTorrent. It defines the protocols and algorithms by which a file can be shared by the protocol participants which are referred to as peers. BitTorrent capitalizes on the bandwidth of peers by forcing them to upload pieces of content to other peers while they download other pieces of that content. The session of transfer of a single content among a set of peers is referred to as torrent, and the complete set of peers sharing a torrent is called a swarm. Peers which have the complete content stored at their computer and therefore only upload content are referred to as seeds, while peers which have only parts of the content are called leaches. A torrent is alive as long as there is at least one seed in the torrent.
Files transferred using BitTorrent are split to fixed sized pieces which are typically of size 256 KB. Each piece is split into fixed sized blocks which are typically of size 16 KB. Blocks are the transmission units of the network, but the protocol only accounts for transferred pieces.
A user joins an existing torrent by downloading a .torrent file usually from a Web server. The .torrent file contains metadata of the file to be downloaded, e.g. the number of pieces and a hash value of each piece. It also includes the IP address of the so-called tracker of the torrent. The tracker is the only centralized component of BitTorrent, but it is not involved in the actual distribution of the file. It only keeps track of peers currently involved in the torrent and collects statistics of it. Recently an alternative tracker-less method has been included as part of BitTorrent. This method uses a “distributed sloppy hash table” (DHT) that stores and exchanges peer's information at the peers themselves.
When joining a torrent, a new peer asks from the tracker a list of IP addresses of peers to connect to. Typically, the initial list includes about 50 peers that are randomly selected by the tracker. These peers will form the initial peer set of the new peer. The initial peer set can be dynamically modified. The modification is responsive to peers that connect directly to the new peers or by peers leaving the torrent. Each peer reports its state to tracker every 30 minutes or when disconnecting from the torrent. The state includes the amount of bytes uploaded and downloaded from the beginning of joining the torrent. The peer will also connect the tracker to receive a set of new peers when its set falls below some given threshold.
Every peer exchange message and file blocks with other peers in its peer set via a wired protocol which is based on TCP/IP. A peer uses these information messages to identify what pieces exist at which peers. This information allows him to request missing pieces from its peer set. Every peer maintains two Boolean states with any other peer it has connection to, namely interested/uninterested and choke/unchoke. When peer S is interested in pieces from peer D it send an interested message to it. In turn, peer D can either decide to include peer S as one of its downloaders in which case we will say that it unchokes peer S, or it may decide to choke peer D, resulting in no blocks uploaded to it for the unchoke period.
Two core algorithms govern the behavior of peers with each-others: Choke Algorithm and Rarest First. The choke algorithm defines at each round for each peer what other peers will be unchoked. A round is typically up to every 10 seconds. In general, peers are unchoked on a tit-for-tat basis that is the peers that upload the most blocks to that serving peer will be reciprocated. Another mechanism called optimistic unchoking randomly unchokes “weaker” peers to allow new peers who don't have yet sufficient blocks to account for a reasonable upload rate to “play in the game”.
The rarest first algorithm defines for each peer what pieces to request in what order. In general, the peer will first ask for the piece with the smallest number of holders, thus contributing to a good dissemination of the content pieces between the entire peers population.
BitTorrent is quite effective for file transfer but it is not adequate for the sake of streaming since pieces of content are not being downloaded sequentially. Recently, a large number of web companies began to offer streaming “TV-like” services which are based on BitTorrent with some adaptation. This type of service is informally referred to as P2PTV.
P2PTV works by dividing the content stream into segments each one composed of a sequential number of pieces. On every given time frame, one segment is the active segment. When a new peer is joining a channel it begins to participate in a torrent session of the active segment. In fact, different peers view the channel in some time variation, each one views at a given time a certain piece of the active segment. Rather than storing pieces on the hard-drive, like with the traditional protocol, P2PTV uploads blocks directly from the memory buffers.
There is a need to provide an efficient method, system and computer readable medium for providing visual content to a user.